Goto 문

3. 비판

고급 언어에서 `goto` 문은 오랫동안 비판의 대상이 되어 왔다. 가장 큰 이유는 `goto` 문을 과도하게 사용하면 프로그램의 제어 흐름이 복잡하게 얽혀 코드를 읽고 이해하기 어려우며, 유지보수가 힘든 이른바 스파게티 코드를 만들기 쉽기 때문이다.^[25]

1960년대와 1970년대에 구조적 프로그래밍이 중요한 프로그래밍 원칙으로 부상하면서 이러한 비판은 더욱 거세졌다. 많은 컴퓨터 과학자들은 프로그램의 논리 구조를 명확하게 표현하기 위해 `goto` 문 대신 순환문(loop)이나 `if-then-else` 문과 같은 구조적인 제어 흐름 구문을 사용해야 한다고 주장했다.^[25]

`goto` 문에 대한 가장 유명하고 영향력 있는 비판은 1968년 에츠허르 데이크스트라가 발표한 "Go To Statement Considered Harmful"(goto 문은 해롭다고 간주된다)이라는 제목의 서신이다.^[26] 데이크스트라는 이 글에서 `goto` 문이 프로그램의 실행 흐름을 예측하기 어렵게 만들어 프로그램의 정확성을 분석하고 증명하는 작업을 매우 복잡하게 만든다고 지적하며, 고급 언어에서는 `goto` 문을 폐지해야 한다고 주장했다.^[1] 이 서신은 프로그래밍 커뮤니티 내에서 `goto` 사용에 대한 격렬한 논쟁을 촉발하는 계기가 되었다.^[2]

`goto` 문은 프로그램의 구조화를 방해하고 디버깅을 어렵게 만들며, 버그 발생 가능성을 높이는 원인으로 지목된다. 제어 흐름이 예측 불가능하게 여러 곳으로 이동할 수 있기 때문에 코드의 특정 부분에 도달하는 경로를 추적하기 어렵고, 이는 잠재적인 오류를 찾거나 수정하는 작업을 힘들게 만든다. 또한, `goto` 문 자체만으로는 "이전에 실행한 위치로 돌아가는" 반복의 의미인지, 아니면 "특정 코드 블록을 건너뛰는" 점프의 의미인지 명확히 드러나지 않아 코드의 의도를 파악하기 어렵게 만든다.

실제로 `goto` 문과 관련된 심각한 소프트웨어 오류 사례도 존재한다. 1990년 AT&T의 장거리 전화망을 마비시켰던 대규모 장애는 제어 흐름 변경과 관련된 문제였으며^[24], 2014년 애플의 SSL/TLS 구현에서 발견된 심각한 보안 취약점(CVE-2014-1266), 일명 '''goto fail''' 버그는 `goto` 문을 잘못 사용하여 필수적인 보안 검증 로직을 건너뛰게 만든 것이 원인이었다. 이러한 사례들은 `goto` 문이 코드의 논리적 오류를 유발하고 발견하기 어렵게 만들 수 있음을 보여준다.

이러한 비판과 문제점 때문에 많은 현대 프로그래밍 언어(Java, Python 등)는 아예 `goto` 문을 지원하지 않거나 사용을 강력히 권장하지 않는다. 비록 특정 상황에서 `goto`가 간결한 해결책이 될 수 있다는 주장도 있지만^[27], 구조적 프로그래밍 원칙과 코드의 명확성, 유지보수성을 중시하는 현대 소프트웨어 개발 환경에서는 `goto` 사용을 최소화하거나 피하는 것이 일반적인 경향이다.

3. 1. goto 문 논쟁

3. 2. 데이크스트라의 주장

3. 3. goto 옹호론

• 다단계 중단(Multi-level break/continue): 여러 겹으로 중첩된 for 문이나 while 문 같은 루프 구조에서 한 번에 바깥으로 빠져나가거나 다음 단계로 넘어갈 때 유용하다. 이는 C에서 자주 사용되는 방식이다. Java는 `goto` 키워드를 예약했지만 구현하지 않는 대신, 레이블이 있는 `break` 및 `continue` 문을 제공하여 이 기능을 지원한다. Java 설명서에 따르면, C 언어에서 `goto` 문의 가장 흔한 사용(약 90%)이 바로 이러한 다단계 중단이었다고 한다.
• 오류 처리 및 자원 정리: 예외 처리 기능이 없는 언어에서 오류 발생 시 처리를 특정 위치로 모으거나, 함수 종료 전에 할당된 자원을 해제하는 등의 정리 코드를 중앙 집중화하는 데 사용된다. C++에서는 RAII 기법이나 `try-catch` 예외 처리를 통해 이를 대체할 수 있다.
• 유한 상태 기계 구현: 상태 전이 테이블과 `goto` 문을 사용하여 상태 간의 전환을 구현하는 데 사용될 수 있으며, 특히 자동으로 생성된 코드에서 유용하다.
• 코드 가독성 및 간결성 향상: 특정 상황에서는 `goto`를 사용하는 것이 코드를 더 읽기 쉽고 따라가기 쉽게 만들며, 코드 중복을 줄여 프로그램을 더 작게 만들 수 있다.
• 레거시 코드 수정: 대규모 함수나 복잡한 구조를 가진 기존 코드를 수정할 때, 광범위한 리팩터링이나 코드 중복을 피하기 위해 제한적으로 사용될 수 있다.

4. 변형

'''goto''' 문은 기본적인 형태 외에도 다양한 변형이 존재한다.

=== 계산된 goto 문 (Computed GOTO) ===

계산된 goto 문은 어떤 수식의 값이나 변수에 저장된 레이블을 이용해 프로그램의 여러 지점 중 한 곳으로 이동하는 방식이다.^[6] 이는 일반적인 goto 문보다 코드 흐름을 파악하기 어렵게 만들 수 있는데, 프로그래머가 코드를 보더라도 다음에 어떤 부분이 실행될지 예측하기 어렵기 때문이다.

• '''베이직''': `ON ... GOTO` 문을 통해 수식 값에 따라 지정된 여러 줄 번호 중 하나로 분기할 수 있다. 이는 특정 조건에 따라 여러 경우로 나누어 처리할 때 유용하다.
• '''C''': 직접적인 계산된 goto는 없지만, Switch 문이 비슷한 기능을 제공한다. 일부 컴파일러(특히 GCC)는 표준 C/C++ 문법이 아닌 확장 기능으로 계산된 goto를 지원하기도 한다. 이 확장 기능을 사용하면, 레이블의 메모리 주소를 얻어 포인터 변수에 저장한 뒤, 이 변수를 이용해 해당 레이블로 점프할 수 있다. 이는 포트란의 할당된 goto와 유사하지만, 임의의 포인터 연산 결과를 점프 대상으로 사용할 수 있다는 점에서 더 유연하다. 단, 점프 대상은 현재 함수 내부에만 있어야 한다.
• '''포트란''': `GOTO (레이블목록) 변수` 형태의 계산된 `GOTO` 문이 있었다. 예를 들어, `goto (20,30,40) i`는 변수 `i`의 값이 1, 2, 3일 때 각각 20, 30, 40번 줄로 분기한다.^[6] 현대 포트란에서는 `SELECT CASE` 구문을 사용하는 것이 권장된다.
• '''PL/I''': `LABEL` 데이터 타입을 사용하여 계산된 goto와 유사한 기능을 구현할 수 있다. 레이블들을 배열에 저장하고 배열 인덱스를 이용해 원하는 레이블로 분기하는 방식이다.

• '''포트란''': 포트란 95 이전 버전에서는 `ASSIGN` 문을 사용하여 문장 레이블(줄 번호)을 정수 변수에 할당하고, `GOTO 변수` 형태로 해당 레이블로 점프할 수 있었다. 하지만, 레이블이 할당되지 않은 변수를 사용하거나 할당된 변수 값을 프로그래머가 실수로 변경하는 경우 예기치 않은 동작이나 버그를 유발할 수 있어 문제가 되었다.^[4] 이러한 문제 때문에 이후 버전에서는 삭제되었다.^[4]

• '''PL/I''': `LABEL` 데이터 타입을 사용하여 할당된 goto와 유사한 기능을 구현할 수 있다. 레이블 변수에 특정 레이블 값을 할당한 뒤, 이 변수를 이용해 분기한다.

• '''Scheme''': 컨티뉴에이션을 언어 차원에서 강력하게 지원한다. 이를 이용하면 코루틴이나 협력적 멀티태스킹과 같은 복잡한 제어 흐름을 비교적 쉽게 구현할 수 있다.
• '''C''': setjmp/longjmp 함수를 통해 제한적인 형태의 컨티뉴에이션(주로 현재 함수 바깥의 상위 함수로 탈출하는 용도)을 사용할 수 있다.
• '''Common Lisp''': `GO` 연산자가 어휘적 범위를 벗어난 점프 시 스택을 해제하는 기능을 포함하여 컨티뉴에이션과 유사한 동작을 할 수 있다.

• '''COBOL''': 1985년 ANSI 표준 이전의 COBOL에서는 `ALTER` 문을 사용하여 이미 작성된 `GO TO` 문의 목적지를 동적으로 변경할 수 있었다.^[7] 이는 코드의 유연성을 높이려는 의도였지만, 프로그램의 흐름을 예측하기 어렵게 만들어 많은 비판을 받았고 거의 사용되지 않았다.
• '''PL/I''': `LABEL`이라는 데이터 타입을 제공하여 레이블 자체를 변수에 저장하거나 배열로 관리할 수 있게 했다. 이를 통해 계산된 goto나 할당된 goto와 유사한 기능을 구현할 수 있었으며, 심지어 현재 프로시저 블록 외부로 점프하는 것도 가능했다. 다른 프로시저에게 레이블을 인수로 전달하여 호출된 프로시저가 호출한 프로시저의 특정 지점으로 직접 점프하여 종료하는 것도 가능했다. 이 경우 점프 시 호출 스택이 자동으로 정리(pop)된다.

5. 대안

고급 언어에서 goto 문은 과도하게 사용될 경우 코드를 읽고 유지하기 어려운 스파게티 코드를 만들기 쉽다는 비판을 받아왔다. 1960년대와 1970년대에 구조적 프로그래밍이 부상하면서, 많은 컴퓨터 과학자들은 프로그램이 항상 'goto' 문 대신 순환문, 'if-then-else' 문과 같은 구조적 제어 흐름문을 사용해야 한다고 주장했다.^[25] 에츠허르 데이크스트라는 1968년 "goto 문의 해로움"이라는 글에서 'goto' 문이 프로그램의 정확성을 분석하고 증명하는 것을 어렵게 만들기 때문에 제한해야 한다고 주장하며 이러한 비판의 계기가 되었다.^[26][1]

'goto' 문 없이 프로그램을 구조화하는 주요 대안들은 다음과 같다.

'''구조적 프로그래밍'''

현대적인 서브루틴 개념은 EDSAC 프로그래밍 과정에서 데이비드 휠러에 의해 고안되었다. 그는 서브루틴 호출 명령어가 없는 기계에서 호출과 반환을 구현하기 위해 휠러 점프라는 자기 수정 코드 기법을 사용했다. 이는 라이브러리 루틴의 중첩 실행을 통해 프로그램을 구조화하는 길을 열었다.

이후 파스칼과 같은 고급 언어들은 구조적 프로그래밍을 지원하도록 설계되었다. 이 언어들은 서브루틴(프로시저 또는 함수)과 함께 다음과 같은 제어 구조를 도입하여 'goto' 문의 필요성을 줄였다.

• 'while', 'repeat until' 또는 'do while', 'for' 문을 사용한 반복문
• 'switch' (또는 'case') 문을 사용한 다중 분기

• 조기 종료: C와 같은 언어에서는 'break' 문을 사용하여 루프를 즉시 종료하거나, 'continue' 문을 사용하여 다음 반복으로 넘어갈 수 있다. 이는 불필요한 'if'나 'while' 문 추가 없이 제어 흐름을 단순화한다. Java와 같은 일부 언어는 여러 단계의 중첩된 루프를 한 번에 빠져나올 수 있는 "레이블 있는 'break'" 기능을 제공하는데, 이는 'goto'의 흔한 사용 사례 중 하나를 대체한다.^[5][10] Java 설명서에 따르면, 'goto' 문의 약 90%가 다단계 'break' 구현에 사용되었다고 한다.
• 예외 처리: Java의 'try'/'catch'/'finally' 구문이나 C++의 RAII(Resource Acquisition Is Initialization) 기법은 프로그램 실행 중 발생하는 예외적인 상황을 처리하는 구조적인 방법을 제공한다. 예외 처리는 오류 발생 시 현재 실행 지점에서 벗어나 지정된 예외 처리 코드로 제어를 옮긴다. 이는 자원 해제와 같은 정리 작업을 수행하는 데 유용하며, C 언어에서 'goto'가 자주 사용되던 오류 처리 패턴^[5][10]을 대체할 수 있다.^[19][20] C 언어의 'setjmp'/'longjmp' 함수도 유사한 기능을 제공하지만, 예외 처리 메커니즘은 남용될 경우 'goto'처럼 코드 흐름을 이해하기 어렵게 만들 수 있다는 비판도 있다.

6. 언어 지원

많은 프로그래밍 언어는 `goto` 문을 지원하지만, 그렇지 않은 언어도 많다.

'''지원하는 언어'''

• C: `goto` 문을 지원하며, 오류 처리나 다중 루프 탈출 등 특정 상황에서 사용되기도 한다.^[1][2] 리눅스 커널 코드에서도 사용 예를 찾아볼 수 있다.
• C#: `goto`를 지원하지만, 현재 실행 중인 코드 블록 밖으로 점프하는 것은 허용되지 않는다. switch 문 내에서 `case`나 `default` 레이블로 이동하는 데 사용될 수 있다 (`goto case`, `goto default`).^[9]
• 비주얼 베이직 .NET: `goto`를 지원하며, C#과 유사한 제약을 가진다.^[9]
• PL/I: `goto` 문을 지원하며, 블록 외부로 이동할 때 스택을 정리하지만 블록 외부에서 내부로의 이동은 허용하지 않는다.
• 포트란: 과거에는 `goto`가 널리 사용되었으나, 구조적 프로그래밍 기능이 도입되면서 사용이 제한되었다. 특정 형태의 `goto`는 이후 버전에서 삭제되었다.^[3][4]
• PHP: 버전 5.3부터 `goto` 문을 지원하기 시작했다. 이전 버전에서는 관련 기능을 구현한 라이브러리가 사용되기도 했다.^[11][20]
• Perl: 기본적으로 `next` 키워드를 사용하여 명시적인 폴스루(fallthrough)를 구현하지만, 설정을 통해 암시적 폴스루도 가능하다.
• D: 1999년부터 설계된 비교적 최신 언어임에도 `goto` 문을 포함하고 있다.^[19]
• MAD: `TRANSFER TO` 라는 이름으로 `goto`와 유사한 기능을 제공했다.
• APL: 오른쪽 화살표 기호(`→`)를 `goto` 문으로 사용한다.
• 어셈블리어: 기계어의 무조건 분기와 레이블을 통해 `goto`와 동일한 기능을 구현한다.
• 베이직: 초기 버전이나 단순한 형태의 BASIC에서는 분기나 반복을 위해 `goto` 문이 필수적인 경우가 많았다.

• 자바: `goto`가 예약어로 지정되어 있지만 실제로는 사용할 수 없다. 대신 레이블과 함께 사용하는 break나 continue 문을 통해 비슷한 기능을 일부 구현할 수 있다. 컴파일된 바이트코드(`.class` 파일) 수준에서는 GOTO 명령어가 사용된다.^[8]
• 파이썬: `goto` 문을 지원하지 않는다. 재미 삼아 `goto` 기능을 추가하는 비공식 모듈이 존재하기도 한다.
• Seed7: `goto` 문을 지원하지 않으며, `break`나 `continue`와 같이 제어 흐름을 갑자기 바꾸는 문장도 의도적으로 배제했다.
• 에이다: 구조적 프로그래밍 원칙을 강조하며 `goto` 사용을 지양하는 설계를 가지고 있다. 레이블을 정의할 때는 시각적 구분을 위해 꺽쇠괄호(`<<레이블>>`)를 사용한다.
• 함수형 프로그래밍 언어 (예: Scheme): 일반적으로 `goto` 대신 연속(continuation)과 같은 다른 제어 구조를 사용한다.

7. 현재 상황

구조적 프로그래밍의 등장 이후, goto 문은 스파게티 코드를 유발할 수 있다는 비판을 받으며 사용이 줄어드는 추세이다.^[25] 특히 1968년 에츠허르 데이크스트라가 "goto 문의 해로움"^[26]이라는 글을 통해 goto 문이 프로그램의 정확성 분석과 증명을 어렵게 만든다고 주장한 이후, 많은 프로그래밍 언어에서 goto 사용을 제한하거나 다른 제어 구조(예: 반복문, if-then-else 문) 사용을 권장하게 되었다.^[1]

하지만 특정 상황에서는 goto 문이 여전히 유용하다는 주장도 꾸준히 제기되었다. 도널드 커누스는 goto 문이 특정 프로그래밍 구조가 언어에 없을 때 이를 모방하는 기본적인 요소가 될 수 있다고 보았다.^[27] 브라이언 커니핸과 데니스 리치 역시 goto 문이 남용될 위험이 크다고 경고하면서도, C 언어에서 중첩된 루프를 한 번에 빠져나가거나 함수 끝에서 오류를 처리하는 등의 제한적인 상황에서는 유용할 수 있다고 언급했다. 실제로 C 프로그래밍에서는 이러한 용법이 흔하며, 특히 내장된 예외 처리 기능 부족으로 오류 처리 패턴에서 goto가 사용되기도 한다.

리눅스 커널과 같은 대규모 프로젝트에서도 goto 문은 여전히 사용되고 있다. 리누스 토르발스를 비롯한 일부 개발자들은 goto 문을 적절히 사용하면 프로그램의 속도, 크기, 코드 명확성을 향상시킬 수 있다고 주장한다. 2013년 기준으로 리눅스 커널 코드에는 약 10만 개의 goto 문이 사용된 것으로 알려졌다.

현재 C 언어를 제외한 많은 주류 언어에서는 goto 문을 거의 사용하지 않는다. Java나 Python 같은 언어는 아예 goto 문을 지원하지 않는다. 대신 break, continue, 예외 처리, 꼬리 호출 최적화, RAII(C++) 등 더 구조화된 방식으로 제어 흐름을 다루는 기능을 제공한다. Java의 경우, goto 키워드는 예약되어 있지만 실제 기능은 구현되지 않았고, 대신 레이블을 지정하여 여러 단계의 루프를 탈출할 수 있는 `break` 및 `continue` 문을 제공한다. 이는 C에서 goto 문의 가장 흔한 사용 사례(다단계 탈출)를 대체하기 위한 것이다.

반면, PHP(버전 5.3부터)^[11][20], D 언어^[19], C# 등 일부 현대 언어에서는 여전히 제한적인 형태로나마 goto 문을 지원하고 있어, 특정 상황에서의 유용성을 인정받고 있음을 보여준다.

goto 문이 유용하게 사용될 수 있는 대표적인 상황은 다음과 같다.

• 중첩된 루프나 조건문에서 한 번에 빠져나와야 할 때 (다단계 break/continue 기능이 없는 경우).
• 오류 발생 시 함수 뒷부분의 정리 코드(예: 할당된 자원 해제)로 바로 이동해야 할 때 (특히 예외 처리 기능이 없거나 비효율적인 언어).
• 유한 상태 기계를 구현할 때 상태 전환을 명확하게 표현하기 위해.
• 코드를 재구성하기 어려운 레거시 코드를 수정할 때 임시방편으로 사용될 수도 있다.

참조

_[1] 인용구
_[2] EWD On a Somewhat Disappointing Correspondence 1987-05
_[3] 간행물 American National Standard – Programming Language FORTRAN American National Standards Institute 1978
_[4] 간행물 Information technology – Programming languages – Fortran – Part 1: Base language ISO/IEC
_[5] 웹사이트 nathanhoad/godot_dialogue_manager https://github.com/n[...] 2022-07-28
_[6] 설명
_[7] 설명
_[8] 인용
_[9] 웹사이트 GoTo Statement - Visual Basic https://learn.micros[...] 2021-09-15
_[10] 웹사이트 ha ha only serious http://catb.org/~esr[...]
_[11] 웹사이트 PHP: 新機能 - Manual http://www.php.net/m[...]
_[12] 서적 文芸的プログラミング
_[13] 학술지 Go To Statement Considered Harmful
_[14] 학술지 Structured Programming with go to Statements Computing Surveys
_[15] 논문 Structured Programming http://homepages.cs.[...] NATO Scientific Affairs Division, Brussels, Belgium
_[16] 논문 '"GOTO Considered Harmful" Considered Harmful' https://web.archive.[...]
_[17] 학술지 GO TO 論争：第2部 GO TO 論争 共立出版
_[18] 학술지 "構造的プログラミング −批判と支持−" 共立出版
_[19] 웹사이트 Language Reference Goto Statement http://dlang.org/sta[...]
_[20] 웹사이트 PHP マニュアル goto http://php.net/manua[...]
_[21] 학술지 "GO TO 論争：第3部 解説" 共立出版
_[22] 서적 소프트웨어クリーンルーム手法 日科技連
_[23] 학술지 "ダイクストラ教授とふた付き命令" 共立出版
_[24] 웹사이트 All Circuits are Busy Now: The 1990 AT&T Long Distance Network Collapse http://users.csc.cal[...]
_[25] 서적 C 언어 프로그래밍 대영사
_[26] 웹사이트 Go To Statement Considered Harmful http://www.acm.org/c[...]
_[27] 웹사이트 Structured Programming with Goto Statements http://pplab.snu.ac.[...]